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Abstract 

TUNIS  (Toronto  UNIversity  System)  is  a  portable  operat¬ 
ing  system  that  is  compatible  with  Version  7  of  UNIX  (a 
Western  Electric  trademark).  In  general  a  program  that  exe¬ 
cutes  under  the  UNIX  “kernel"  can  as  well  run  under  TUNIS. 
The  format  of  TUNIS  files  is  the  same  as  that  of  UNIX,  so 
TUNIS  and  UNIX  should  be  transparently  interchangeable 
(except  for  some  minor  caveats). 

TUNIS  has  been  developed  for  a  large  class  of  usages; 
besides  being  a  general  purpose  operating  system,  it  is 
intended  to  support  standalone  workstations  based  on  16-bit 
microprocessors,  to  serve  as  the  software  basis  '‘for 
microprocessor  development  systems,  etc. 

Except  for  a  snail  base  layer  of  assembly  language 
(about  4X  bytes)  all  of  TUNIS  is  written  in  Concurrent 
Euclid  (CE).  CE  is  a  language  designed  to  support  the 
development  of  high  performance,  highly  reliable  system 
software.  The  CE  compiler  is  small  (50X  bytes,  4  passes) 
and  fast  and  has  high  quality  replaceable  code  generators 
for  various  architectures  (PDP-11,  Motorola  66000,  Motorola 
6809,  VAX,  etc.)  CE  supports  modules,  a  language  feature  for 
packaging  data  with  procedures.  It  supports  concurrency 
using  monitors  as  defined  by  C.A.R.  Ecare. 

The  internal  organization  of  TUNIS  is  entirely  dif¬ 
ferent  from  that  of  UNIX.  It  is  highly  structured,  consist¬ 
ing  of  layers  that  are  CE  modules.  Each  module  supports  a 
new  level  of  abstraction,  which  is  enforced  by.  CE's 
imnor t/expor t  (scope''  rules.  For  example,  one  module  is  the 
"memory  manager*,  which  implements  the  abstraction  of 
address  spaces  in  which  user  processes  execute.  Outside  the 
Memory  Manager,  it  is  immaterial  whether  address  spaces  are 
supported  by  swapping  or  paging. 

At  present  (April  1962)  an  experimental  version  of 
TUNIS  is  running  on  the  FDP-11.'  About  half  of  the  modules 
that  make  ud  Tunis'  have  been  tested  on  the  Motorola  68000. 
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An  Overview  of 
TUNIS :  A  UNIX  Look-Alike 
Written  in  Concurrent  Euclid 


The  Fortran  cf  Operating  Systems 

UNIX,  developed  at  Bell  Laboratories ,  is  a  small  power¬ 
ful  operating  system,  particularly  good  at  supporting  pro¬ 
gram  development  ard  text  processing.  It  has  been  widely 
adopted  at  universities  during  the  last  eight  years  ana  is 
now  spreading  rapidly  among  industrial  users.  Although  not 
developed  with  portability  in  mind,  it  has  been  moved  from 
the  PDP-11  to  other  architectures  including  the  Interdata 
632,  VAX,  Zilog  6000,  etc. 

To  the  user  cf  each  cf  these  systems  supporting  UNIX, 
each  system  appears  to  be  (almost)  the  same.  Thus  the  user 
no  longer  needs  to  be  particularly  concerned  about  what 
manufacturer  supplies  his  computer  system.  This  is  a  con¬ 
venience  that  can  be  ccmpa red  with  the  development  cf  For¬ 
tran,  which  freed  users  from  irrelevant  details  like 
instruction  formats.  Fortran  spread  rapidly  from  architec¬ 
ture  to  architecture  and  rapidly  captured  a  large  user  audi¬ 
ence.  Fortran  put  the  computer  in  the  hands  of  a  new  user 
community  (scientists  who  were  non-computer  specialists) 
because  (1)  Fortran  compilers  could  be  built  without  great 
difficulty  for  different  architectures  and  (2)  the  language 
was  relatively  convenient  to  use.  It  has  been  predicted  by 
some  that  UNIX  will  become  the  standard  operating  system  for 
the  16-bit  microprocessors.  If  UNIX  even  approaches  this 
widespread  acceptance,  then  its  portability  and  convenient 
user  interface  will  have  earned  it  the  title  cf  "the  Fortran 
of  operating  systems". 

No  doubt  UNIX  can  be  improved  (to  create  the  Pascal  of 
cperatirg  systems?).  But  there  are  significant  advantages 
of  a  relatively  pure  UNIX  (or  pure  UNIX  look-alike)  includ¬ 
ing  the  following:  ' 

(1)  Portable  users:  the  user  does  net  care  what  architecture 
he  is  using  and  can  move  from  system  to  system  without  re¬ 
training. 
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(2)  For  table  user  software!  the  users'  programs  can,  in  most 
cases,  he  moved  iron  architecture  to  architecture  because 
the  system  facilities,  including  file  management,  remain 
constant. 

( 3 h  Portable  documentation:  only  one  set  of  documentation, 
including  educational  materials,  is  sufficient. 

(4)  Portable  operating  system:  the  same  system  software, 
written  in  a  high  level  language,  runs  on  all  the  architec¬ 
tures,  so  only  one  operating  system  maintenance  effort  is 
required  for  all  the  architectures. 

These  are  the  advantages  of  an  operating  system  that  behaves 
like  UNIX ;  but  of  course  that  operating  systen  need  not  be 
the  original  one  developed  by  Pell  Labs. 


Why  TUNIS? 

TUNIS  (Toronto  UNIversity  System)  evolved  from  teaching 
about  operating  systems.  The  first  version  was  designed  as 
a  graduate  course  project  in  Fall  1979.  This  effort  was 
academically  so  successful  (i.e.,  we  learned  a  lot)  that  a 
more  ambitious  UNIX-compatible  operating  system  was 
attempted  in  Fall  1982  by  the  next  generation  of  the  course. 
This  time  we  got  most  of  it  programmed  and  inevitably 
discovered  that  some  interfaces  were  poorly  conceived. 
Meantime,  out  of  this  'effort  the  Concurrent  Euclid  language 
was  designed  as  a  subset  of  Fuclid  with  concurrency  added. 
Patrick  Cardozo  took  up  the  challenge  and  as  his  M.Sc.  pro¬ 
ject  implemented  and  tested  a  major  part  of  the  system  on  a 
PDP-11  model  23.  David  Galloway  wrote  a  prototype  file 
manager.  -  The  torch  was  then  passed  to  Mark  Mendell  (an 
M.Sc.  student),  Professor  David  Barnard  and  other  willing 
staff  and  students. 

Why  all  this  effort  when  the  real  UNIX  already  exists? 
The  various  answers  to  this  question  include: 

(1)  We  wanted  to  develop  a  convincing  example  of  the  use  of 
a  high-level  language  for  production  software.^  (We  have 
come  to  think  of  UNIX's  implementation  language  "c”  as  a 
gocd  replacement  for  assembler  but  not  really  a  high  level 

language . ) 

(2)  We  wanted  to  develop  a  convincing  example  of  the  use  of 
processes  and  monitors  for  production  software.  (By  con¬ 
trast,  synchronization  inside  UNIX  is  basically  a  monolithic 
monitor  * enhanced  by  the  trick  of  masking  some  interrupts 
when  things  look  dicey.) 

(3 )  We  wanted  to  d enons t r a te  that  Euclid  is  a  viable  tool 


' 

, 


I  *j  j 


. 


for  hard-ccre  system  software  such  as  operating  systems, 
process  control  and  enhedded  microcomputer  systems. 

(4)  We  hoped  it  might  he  possible  to  prove  part  or  all  of 
the  system  correct  (at  some  unspecified  future  date). 

But  mostly  we  wanted  to  see  if  we  could  build  a  beauti¬ 
fully  structured  production  operating  system,  without  sac¬ 
rificing  a  significant  amount  of  'system  performance.  Along 
with  these  rather  idealistic  goals,  v;e  have  many  practical 
applications  for  TUMI?  in  mind,  such  as  supporting  personal 
work  stations,  supporting  microprocessor  development  sys¬ 
tems  ,  etc. 

We  have  resisted  the  temptation  to  improve  upon  the 
features  of  UNIX  until  we  can  do  as  well  as  UNIX.  But  once 
we  do  as  well  as  UNIX  we  have  many  vague  plans,  including: 

(1)  Making  the  file  system  fail  safe, 

(2)  Distributing  the  file  system  across  more  than  one 
site, 

(3)  Developing  a  mul t iple-CPU  version  of  TUNIS  (this 

should  be  easy  because  TUNIS  uses  honest  system 
processes  and  synchronization;  unfortunately  the 
hardware  is  not  very  cooperative).  ' 

(4)  Distributing  some  of  the  operating  system  logic, 
such  as  the  disk  cache,  onto  remote  microprocessors. 
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Experience  with  Toronto  Euclid  lead  1 0  the  design 
Concurrent  -Euclid  (CE).  omits  from  Euclid  complex 

features  (notably  uaremeterized  types)  and  adds  ceatures 
needed  for  TUNIS  "(notably  concurrency  and  separate  compila¬ 
tion  cf  modules).  The  CE  language  has  a  small  (50X  bytes), 
fast,  portable  compiler.  The  CE  compiler  is  a  four  pass 
5elf— compiling*  compiler  with  replaceable  cede  generators. 
It  has  beer  cur  experier.ee  that  a  high  quality,  production 
code  generator  for  CE  can  be  developed  in  ^  to  4  man-months. 
TT-o  to  the  nr e sen t  time  (Aoril  82),  production  code  genera¬ 
tors  exist  for  the  PDP-11,  VAX,  M68000  and  M6809.  These 
code  generators  typically  produce  ^as  good  or  better  code 
than  competing  compilers  such  as  UNIX  s  C  compiler. 
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The  first  step  in  porting  TUNIS  to  a  new  architecture 
is  the  development  of  a  rev  code  generator.  It  is  our  hope 
that  in  at  -east  some  cases,  this  will  be  the  hardest  part 
of  porting  TUNIS. 


Tenets  of  Software  Engineering 

4 

Designing  a  program  such  as  the  Tunis  ..nucleus  is  not 
easy.  (Note:  We^will  use  the  term  nucleus  to  mean  what  is 
called  a  kernel  in  Unix  terminology.  We  will  use  the  term 
kernel  to  mean  a  relatively  small  module  that'does  little 
more  than  allocate  CPU  time  among  system  processes.)  The 
traditional  challenges  to  the  software  engineer  are  present, 
including  these  questions: 


How  do  we  divide  a  large  program  sc  that  it  can  be 
developed  in  parallel  by  more  than  one  person?  (The 
development  question) 

How  can  we  make  the  program  efficient  enough  for  its 
purposes?  (The  performance  question) 

How  can  we  keep  the  program  understandable  so  that'  it 
is  easy  to  maintain?  (The  maintenance  question) 


How  can  we  make  the  program  portable  so  that  it  can  be 
used  cn  a  new  computer  architecture?  (The  portability 
que s  ti  on ) 


These  issues  are  important  to  many  large 
particularly  challenging  in  the  case  of 
nucleus  because  performance  is  critical 
concurrency  is  present. 


programs,  but  are 
ar.  operating  system 
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The  traditional  tools  used  to  desigr  software  include 
the  following.  Ye  attempt  tc  divide  the  program  into  ’’good” 
modules,  where  a  nodule  is  considered  good  when  its  specifi¬ 
cation  car.  be  simply  stated,  independent  of  its  implementa¬ 
tion.  Perhaps  the  best  way  to  discover  gc.cd  modularity  is 
by  functional  de compos iqqcq ,  which  means  dividing  the  pro¬ 
gram  into  parts  based  cn  the  various  functions  the  pregram 
is  to  perform.  For  example,  the  part  of  Tunis  that  imple¬ 
ments  file  updating  should  be  in  a  separate  module  from  the 
part  that  implements  process  forking. 

From  module  to  module,  we  strive  for  limited  visibil¬ 
ity,  sc  each  module  knows  as  little  as  possible  about  other 
modules.  In  CE ,  this  means  we  try  to  shorten  impor t/expor t 
lists  as  well  as  limiting  the  complexity.  of 
i  muor  t  ed /e  xp  or  t  ed  itens.  This  is  called  i.pfcrmat.qqn  hqdqng 
and  means  that  the  interfaces  between  the  different  parts  of 
a  program  are  kept  simple.  Soretimes  we  are  faced  with  a 


. 


■ 

■ 
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tradeoff  between  narrower  interfaces  and  better  performance. 
This  tradeoff  occurs  when  access  to  more  information  allows 
more  effective  scheduling/optimization.  This  tradeoff  deci¬ 
sion  is  quite  difficult  because  in  a  system  like  Tunis,  both 
modularity  and  performance  are  essential. 

Within  an  implementation  we  strive  for  textual  isola- 
tion  of  design  decisions.  For  example,  in  Tunis  the 
scheduling  algorithm  that  allocates  CPU  time  among  processes 
is  located  completely  within  the  kernel.  If  we  make  a  new 
decision  to  schedule  the  processes  by  a  different  algorithm, 
we  know  that  the  kernel  program  is  the  only  text  we  need  tc 
modify.  ' 


We  should  design  a  program  such  as  an  operating  system 
nucleus  as  layers,  much  as  Unix  consists  of  layers.  In 
Unix,  the  interactive  user  deals  only  with  the  outermost 
software  layer;  the  interface  to  this  layer  is  defined  by 
shell  commands,  editor  commands  and  other  terminal  oriented 
interactions.  This  outermost  software  layer  consists  of 
user  processes.  These  processes  access  the  next  layer  of 
Unix,  v;hich  is  the  nucleus.  The  Tunis  nucleus  is  imple¬ 
mented  as  a  number  of  layers,  which  are  implemented  as  CF 
modules . 


A  system,  such  as  the  Tunis  nucleus,  can  ’  be 

thought  of  as  levels  of  abstraction.  This  means  that  each 
new  layer,  from  the  inside  cut,  implements  new  operations 
that  can  be  used  by  successive  layers.  For  example,  the 
nucleus  provides  operations  to  create,  read,  write  and  des¬ 
troy  files;  given  the  nucleus  layers,  we  can  reason  in  terms 
of  the  "file"  abstraction.  Without  the  nucleus  we  would 
have  to  reason  in  terms  of  lower  level  abstractions 
blocks  of  bytes  on  disk  packs.  Uher  we  design 
layer,  we  can  treat  the  operations  provided  by 
levels  as  instructions  of  an  abstract  machine. 


level  is  not  concerned  with  how  this  abstract 


implemented,  but  rather  only  with  what  it 
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The  Tunis  nucleus  must  manage  the  concurrency  of  asyn¬ 
chronous  devices  and  user  processes.  The  software  structur¬ 
ing  technique  used  inside  the  Tunis  nucleus  to  control  t n i s 
concurrency  -is  t-he  CF  process.  These  CF  processes  inside 
the  nucleus  are  called  s vs  tern  Pluses ses.  Since  Tunis  is 
written  in  CF,  the  obvious  way  to  handle  concurrency  is  to 
use  one  process  for  each  unit  cf  asynchrcnism .  For  example, 
each  terminal  keyboard  operates  asynchronously,  so  each  key¬ 
board  is  controlled  by  a  CF  process. 

These  basic  conceuts  of  software  engineering,  including 
informa  tier  hiding,  levels  of  abstraction,  and  handling  con¬ 
currency  by  nroces  ses  ,  were  used  tc  guide  the  design  of 
Tunis.  '  This  can  be  seen  in  the  structure  of  Tunis;  it  con¬ 
sists  cf  layers  cf  modules,  each  optionally  containing 


. 


processes,  all  "based  on  a  kernel  that  supports  CE  con¬ 
currency  features. 


The  Layer  Structure  of  TUNIS 

The  Tunis  nucleus  consists  of  a  CE  program  supported  by 
a  kernel  written  mostly  in  assembly  language.  This  CE  pro¬ 
gram  consists  of  layers  that  are  CE  modules.  It  is  compiled 
in  parts,  module  by  module.  The  compiled  modules  are  linked 
with  the  kernel  to  make  an  executable  nucleus. 

We  will  present  a  somewhat  idealized  version  of  Tunis's 
layer  structure.  Its  major  layers  starting  from  the  outside 
are  : 


User  manager.  Interprets  systems  calls  from  user 
processes  and  makes  calls  to  lower  levels  to  carry 
out  the  user's  requests. 

File  manager.  Implements  the  fils  system,  using  dev¬ 
ices  supported  by  a  lower  level. 


Memory  manager.  Shares  the  available  physical  memory 
among  user  processes  to  support  their  address 
spaces  (virtual  memories)  and  uses  disk  support 
provided  by  the  next  lower  level  to  store  inactive 
user  processes'  address  spaces. 

Device  manager.  Contains  device  drivers  for  each  peri¬ 
pheral  device  attached  to  the  system. 


Utility  layer.  Supports  common  facilities  needed  by 
the  above  layers,  in  particular: 

Clock  manager:  allows  delaying  and  reading  the  time. 
Physical  Memory  manager:  supports  transfers  of 
*  strings  of  bytes  within  physical  memory. 

Panic  manager:  shuts  down  system  following  disasters. 


Kernel.  Handles  interrupts  and  supports  concurrency  as 
implied  by  op  language  constructs. 

We  will  discuss  these  layers  starting  with  the  bottom. 


Tve  kernel  is  relatively  small  (between  2K  and  4K 
and  is  inherently  machine  dependent,  x  ts  s  p  e  e  ^  is 
critical  tc  the  efficient  execution  cf  the  system.  For 
these  reasons  it  is  written  mostly  in  assembly  language, 
can  think  of  the  kernel  as  extending  the  existing  hardware 
to  support  the  cor. currency  constructs  cf  CE.  x  o  is  as  lx  *2 
are 'building  a  better  version  of  the  hardware  with  more  con¬ 
venient  handling  of  process/process  and  pr ocess/de vice 
irteracticrs.  Once  we  have  implemented  the  kernel,  we  car. 


' 
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ignore  it  a  rd  reason  ^ore  conveniently  in  terms  of  CP's  con- 
currency  constructs. 


.  The  utility  layer  of  Tunis  car.  be  thought  of  as  a  sub¬ 
routine  package  that  supports  operations  needed  by  upper 
layers.  ^  1 1  s  Clock  manager  is  relatively  simple.  Most 
entries  to  -the  Panic  manager  simply  record  the  nature  of  the 
disaster  on  the  system  console  and  halt  the  system.  The 
Tunis  nucleus  executes  in  a  permanently  memory  resident 
address  space.  Depending  on  the  underlying  hardware, 
addresses  in  this  space  may  or  may  not  be  the  same  as  physi¬ 
cal  addresses.  The  Physical  Memory  manager  implements 
transfers  between  this  system  address  space  a'nd  physical 
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hysical  memory. 


The  Major  layers 

Inside  the  Device  manager  layer  there  is  a  Router  that 
accepts  all  I/O  requests  and  passes  them  tc  the  appropriate 
submanager,  such  as  the  Disk  manager. 


Inside  the  Memory  ranager  is  a  Lock  manager  that  forces 
all  or  part  of  a  user's  address  space  into  memory.  This-  is 
necessary,  for  example,  when  a  DMA  (direct  memory  access) 
device  does  I/O  directly  to /from  a  user  process. 
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The  highest  layer  is  the  User  manager.  It  contains  a 
number  of  envelope  processes.  Fach  envelope  acts  as  a 
"guardian  arrel"  for  a  user  process.  t<  The  envelope  process 
waits  for  a  user  process  tc  be  born  via  a  i o r k .  When  this 
happens,  the  envelope  takes  control  and  ushers  the  user  pro¬ 
cess  through  its  lifetime,  handling  any  system  calls  it 
rakes  to  the"  nucleus.  When  the  user  process  dies,  the 
envelope  hardies  its  legacy  including  closing  ary  files  that 
it  ha d* ope n  and  informing  the  Memory  manager  that  the 
address  space  is  defunct.  If  the  user  process's  father  is 
waiting  for  the  death,  the  sen  s  envelope  wakes  up  the 


' 


' 


■ 


father  s  envelope.  Once  this  clean  up  is  finished,  the 
envelope  waits  for  a  new  user  process  to  be  born.  It  is  the 
Family  manager  inside  the  User  manager  that  handles  rela¬ 
tionships  among  processes  as  implied  by  the  fork  and  wait 
system  calls. 

Most  of  the  Tunis  nucleus  is  machine  independent.  Its 
largest  and  most  complex  layer,  the  File  manager,  should  not 
require  any  changes  when  porting  the  nucleus  to  a  ’new 
machine. 


The  Abstraction  of  Address  Spaces 

One  of  the  key  abstractions  implemented  by  Tunis  is 
that  of  an  address  space  for  each  user  process.  This 
abstraction  is  implemented  by  the  Memory  manager  using  phy¬ 
sical  memory  and  disk  space.  Above  the  Memory  manager  the 
User  and  File  managers  assume  that  address  spaces  exist. 
They  pass  down  each  I/O  request  in  terms  of  an  address 
4Si2.riP.tqr,  consisting  of  a  pair:  (space  number,  virtual 
address).  The  User  and  File  managers  are  not  concerned  with 
whether  the  users  are  swapped,  paged  or  permanently  memory 
resident.  These  concerns  are  isolated  in  the  Memory 
manager.  Below  the  Memory  manager,  the  concept  of'  an 
address  space  and  of  user  processes  has  disappeared.  The 
individual  device  drivers  deal  only  in  physical  memory 
addresses.  As  a  result,  a  device  driver  is  relatively  easy 
to  implement,  because  it  does  not  depend  on  mechanisms  such 
as  swapping  and  paging.  U o r  does  a  device  driver  depend  on 
details  of  the  Unix  file  system.  In  brief,  a  device  driver 
is  neutral  to  its  intended  usage,  and  cnce  written,  could  be 
used  for  other  purposes  besides  supporting  Tunis. 


The  Assassin  Process 


When  an  interactive  user  of  Unix  types 


interrupt 


i  he 


user  processes 


a  n  o  t u  ~  ~ 


ch 


character  or  a  quit  character 

ated  with  the  terminal  are  notified,  as  1:  anomer 
had  executed  a  kill  system  call.  The  Telety 
inside  the  D-e vice  manager  layer  detects  these 
It  has  no  way  to  kill  user  processes  because  the  c 
a  user  process  does  net  at  exist  at  this  level, 
type  manager  solves  this  problem  by  providing 
called  Getvictim.  Whenever  this  is  called,  the 
manager  returns  the  identity  of  a  terminal  that  has 
one  of  these  characters. 


associ- 
process 
e  manager 
ar acters  . 
oncept  of 
he  Tele- 
an  entry 
Tele  type 
received 


This  entry  is  called  only  from  a  process  named  the 
Assassin,  which  is  inside  the  User  manager.  When  the  Assas¬ 
sin  receives  the  terminal  s  identity,  it  se^s  c .  - 1  °  o  .to 
notify  each  envelope  whose  user  process  is  associated  with 


£  I 


“ 

. 
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the  terminal.  It  is  the  envelope's  responsibility  to  regu¬ 
larly  check  to  see  if  his  user  process  has  leer,  notified 
(assassinated).  If  so,  the  envelope  takes  the  appropriate 
action,  vnich  often  means  destroying  the  user  process. 


An  example  Module 

\  i 


The  structure  of  TUNIS  will  now  be  explored  in 
detail  by  considering  cne  module,  the  Clock  Manager,  ir 
depth.  This  nodule  is  chosen  because  it  has  a  simple 
tion  and  a  small  implementation.  A  slightly  simplified 
sion  of  it  has  the  following  interface,  as  specified  in 


more 

more 

func- 

ver- 

nv 

.  j  • 


v a r  clock: 

external  module 

exports (UetTime,3etTi me, Delay) 

procedure  CetTine(var  t : Long In t ) =external 
procedure  SetTime(t:LongInt)=external 
procedure  Delay(t:LongInt)=external 
end  module 

This  interface,  called  a  "stub",  serves  as  a  replacemen  V  for 
the  actual  Clock  manager  and  allows  separate  compilation  of 
modules.  The  stub  contains  the  types  of  parameters,  so  CE 
can  do  type  checking  across  compilations. 


The  only  externally  visible  parts  of 
are  its  exported  entry  points  GetTime, 
An  example  of  using  the  Clock  Manager  is: 


the  Clock  Manager 
GetTime  and  Delay. 


Clock .De lay (3  ) 

This  puts  the  caller  to  sleep  for 

The  actual  implementation  of 
following  form: 


3  seconds. 

the  Clock  Manager 


has 


th: 


-  -"lock: 


V  G  i.  \J 


Ul 


r0i 

(2; 


module 

expor.  ts(CetTine,SetTi  me,  Delay) 

var  C lockDo  10  :  {Machine  dependent  part} 
module 

exports  ( \\  a  i  t  S  e  c  o  n  d ) 
urocedure  WaitSecond= 

...body  of  V/ai  tSeccnd  .  . . 
end  module 

var  C  1  oc kMo ni t or :  [Encapsulates  shared  data} 
m c  n i t  or 

experts  (GetTime,  Set  Time  , Delay,  Tick'1 


■ 


; 
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var  now:  Longlnt:^?  {Value  of  clock} 
...other  declarations... 

procedure  GetTime(var  t:  Lcnglnt)= 
imports  (now ) 
begin 
t  :=now 
end  GetTime 


procedure  SetTime ( t :LongInt  )  = 
. . . body  of  SetTine. . . 


procedure  Delay( t : Longlnt ) = 

.  • .  o o d y  oi  ^e  lay  , 

including  wait  statements... 


procedure  Tick  =  {Called 
...body  for  Tick,  vhic 
wakes  up  delayers .  . . 


by  Ticker 
h  updates 


process } 
’new”,  and 


end  monitor 

(Entries  to  Clock  module} 
procedure  GetTime(var  t:Lon&Int)= 
imports (var  ClcckMonitor) 
begin 

C 1  o  ckM o n  i  t  o  r  .  G  e  t T i  me  ( t ) 
end  GetTime 


.  ..analogous  procedures  SetTime  and  Delay... 


{A  process  internal  to  the  Clock 
process  Ticker- 

imper  ts ( va r  C lockMcni t or ,  var 
o  e  g  i  n 
loop 

ClockDcIO.V.’aitSeccnd 
C lo  ckMon i t or . T i ck 
end  loop 
end  Ticker 


U  a  n  a  g  e 


j 


C  c<v 


end  {Clock}  module 


The  Clock  module  contains  four  major  parts,  as  numbere 
in  the  module's  left  margin.  Many  of  the  major  TUMI 
modules  have  this  general  form?  the  parts  are: 


1.  A  ToIO  module.  This  contains  machine  dependencies  and 
activates  a  particular  device.  Ir.  the  case  of  the  Clock 
Manager ,  the  device  is  the  hardware  clock.  Uhe n  TUNIS  is 
ported  to  a  new  machine  the  various  To IG  modules  in  general 
must  be  re-vritten,  because  the  devices  cf  the  new  machine 
will  require  different  logic  to  drive  them. 


T3  C/J 


' 


. 
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2.  A  monitor.  This  contains  data  shared  among  processes. 
In  the  case  of  the  Clock  Manager  this  data  is  the  variable 
now  which  maintains  the  value  of  the  clock.  A  monitor 
contains  conditions  ,  which  are  queues  of  processes  waiting 
for  certain  events  such  as  completion  of  an  interval  of 
s 1 eep . 

2.  Module  entries.  These  are  the  procedures  that  are 
exported  from  the  module  and  represent  the  interface  to  the 
nodule.  In  the  case  of  the  Clock  Manager,  these  entries 
simply  route  requests  directly  to  the  Clock  Monitor,  which 
carries  cut  the  request. 

4.  An  internal  process.  There  is  typically  one  process  (or 
several)  that  calls  the  monitor  occasionally.  These 
processes  nay  be  device  drivers,  as  in  the  case  of  the 
Ticker  process  in  the  Clock  Manager.  In  some  cases,  an 
internal  process  is  an  "ager";  for  example  the  Cache  Manager 
has  a  process  that  repeatedly  sleeps  via  "clock  .Delay"  and 
then  enters  its  ronitor  to  consider  reallocation  of  the 
buffers  in  its  pool.  In  ether  cases  an  internal  process  may 
be  a  courier  or  slave  process;  for  example,  the  Memory 
Manager  has  a  Swapper  process  that  repeatedly  enters  its 
monitor  to  get  a  request  for  swapping  and  calls  the  Disk 
Manager  to  perform  the  swap. 


Programming  Conventions 

The  programming  of  the  modules  of  TUNIS  is  highly  dis¬ 
ciplined  in  that  it  is  written  in  CD  and  it  conforms  to  the 
- 

following  conventions. 


1.  There  are  no  interrupts.  Interrupts  are  hidden  in 
ke  rnel . 


the 


process.  This 


mean 


AH  10  is  synchronous  with  its  invoking 

that  a  process  that  activates  a  device  waits  until  the 

device  completes  its  requested  action.  Of  course  other 

processes  are  free  to  continue. 


3.  System  processes  are  never  killed.  All  system  processes 
ir  TUNIS  are  created  at  system  start-up  and  continue  to 
exist  till  TUNIS  is  shut  down.  The  concept  of  dynamic  crea¬ 
tion  and  deletion  of  user  processes  is  implemented  cy  allo¬ 
cating  and  deallocating  envelope  processes.  hilling  a  user 
process  simply  deallocates  its  envelope. 

4.  Unpredicted  errors  and  exceptions  in  TUNIS  are  fatal. 
However ,  predicted  errors  are  handled  cy  programming  in  CE. 
(Note  that  attempting  to  handle  unpredicted  error  conditions 
in  basic  system  software  is  at  cest  extremely  risky.) 


;* 
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) 


With  these  conventions,  the  progr 
TUNIS  is  relatively  -straight  forv/ard 
disallow  practices  that  make  many 
understand  and  maintain. 


arming  and  logic  of 
.  These  conventions 
systems  difficult  to 


Entry  Points 


of  the  TUN  I S  Kernel 


In  an  ideal  world  the 
ports  the  functions  of 
implementation,  the  kernel 
bier. 


hardware  processor  directly  sup- 
TUNIS's  kernel.  Put  in  an  actual 
is  generally  programmed  in  assem- 


The  kernel 


supports  the  following  functions: 


1.  Process  synchronization.  The  compiler  automatically  gen¬ 
erates  calls  to  kernel  entries  for  each  entry  to  or  exit 
from  a  monitor,  for  each  signal  and  wait  statement,  and  for 
the  “empty”  function  that  tests  if  a  condition  queue  empty. 
The  compiler  also  generates  calls  to  initialize  descriptors 
for  monitors  and  for  condition  queues. 


2.  10  control.  The  kernel  supports  routines  called  SeginIC, 
WaitIC  and  Er.dlO,  which  support  synchronous  device  opera¬ 
tions  (mere  on  this  below). 


3.  User  control.  The  kernel  supports  an  operation  called 
Hurl'ser  that  transfers  control  from  an  envelope  process  tc 


its  corresponding  user. 


This 


domains,  i . e . , 

The  user  continues  to 


setting  the 


transfer 

V.  i 


implies  a  change 


i  n 


Hardware  protection  registers. 


en ve lone  via  a  t r a u  .  This  return 


o  e 


t  i  o  n  s  t  a 


Cl  .to 


4-  V  2 
U  i 1  Cl  L 


o : 


execute 
re  tu 

tukis 


until 


it 


implies 


returns  tc 
resettle?  the 


the 

ore- 


Basic  Be vice  Management 


As  has  leer,  mentioned,  each  device  is  controlled  via 
kernel  procedures  called  by  a  system  process.  Bor  example, 
the  device  driver  for  the  keyboard  for  terminal  number  1  has 
the  for 


°  a  "m : 


loop 

Terri  nalDoIO.C- etc  harl(c) 
TerminalMcnitor.BufferCharl(c) 


en 


1  ocr 


This  repeatedly  gets  character  c  from  the  device  and  calls  a 
monitor  to  store  th°  character  in  a  buffer. 

The  urocedure  GetCharl  in  the  Terminal  ranager  s  BcIP 
module  car  be  written  as  follows  for  a  FDF-il. 


' 


■ 


■ 
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procedure  Ge t Chari ( var  c:Char)= 
imports  (  BeginIO,Wa  i  tIO.EndIO) 
begi  n 

const  input CharReady : =7 

var  t tyllnputStatus (a t  176500#£ )  :  se t  of  0..7 
var  t tyl InputBuf fer ( at  176502^8 ): Char 
Begin  10 

if  input CharReady  not  in  ttyll nputS ta tus 
the  n 

WaitlO(ttyllnputld) 
end  if 

c:=ttyllnuut Buffer 
SndIO 

end  Get  Chari 


This  procedure  uses 
175300  and  175502: 


am 
f  r  om 


the  second  holds 


locations 
the  device 
charac  ter 
kernel  disables 
the  executing 


device  registers  at  octal 
the  first  gives  the  status  of 
the  nost  recently  received 
the  keyboard.  The  BeginlO  entry  of  the 
all  interrupts.  The  WaitIC  procedure  blocks 
process  until  the  read  operation  is  corplete,  i.e.,  until 
the  device  interrupts  the  CPU.  During  the  wait,  the  inter¬ 
rupts  are  re-enabled  and  ether  processes  are  executed.  When 
WaitlO  returns,  the  next  character  from  the  keyboard  is  in 
t  tyl  I  npu  tBuf  f  e  r  ;  the  interrupts  are  again  disabled  -'and 
remain  disabled  until  EndlO  is  called.  The  execution  of  the 
WaitlO  is  conditional  in  this  procedure  to  avoid  the  over¬ 
head  of  waiting  when  the  next  character  is  already  avail¬ 
able. 


This  approach  to  basic  device 
legin/Wai t /Tnd  10,  provides  a  fast,  clean  interface  to 
ices.  Of  course,  lasic  procedures  such  as 


using 


machine  dependent  and  must 
machine.  '  Fortunately  the 


managemen t , 

de  v- 

Cet Chari  are 
a  new 


na 


e  replaced  when  porting  to 
y  can  be  written  in  CE  for  memory 
such  as  the  PDP-11.  Put  for  nor- 

fr. 


^ped  device  registers 
mapped  architectures  such  as  the  TPM  System/360,  support  of 
new  devices  entails  modifying  the  kernel  to  <^mit  explicit 
"Start  10”  machine  instructions. 


Structure  c 


Envelopes 


In  UNIX  a  new  user  process  is  create 
,ys  tern  call.  This  is‘  implemented  in 
nvelope  processes  wait  to  be  allocated, 
.he  procedure  GetNewUser  ir  the  Fanil 
decked  until  a  fork  occurs.  When  a  fork 
■he  new  user  processes  identification,  a 
■utes  the  user's  program  via  the  kernel 

t  ermin 

e 

pro 


_ _  _  a gram  via  the  kernel's 

ventually,  either  the  user  process  termin 
exit  system  call  or  it  is  terminated  by 
all  invoked  by  another  user  process. 


d  by  the  fork 
TUNIS  by  having 
The  envelope  calls 
y  Manager  and  is 
occurs  ,  it  gets 
nd  repeatedly  exe- 
P.unUser  procedure, 
ates  f itself  by  the 
the  "kill"  system 
When  termination 


< 
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occurs,  tne  envelope  informs  the  Family  Manager  yia  the  pro¬ 
cedure  Released ser  and  then  again  invokes  Fami  ly.Ge  tNewUser . 
nereis  a  simplified  version  of  the  reentrant  procedure  exe¬ 
cuted  Dy  all  the  envelope  processes. 

loop  {For  each  user  to  run,  i.e.,  forever} 

I amily. GetNewUser  {Firth  of  user} 

•  •  • 

loop  (For  each  user  request} 

HunUser  {User  process  runs!} 
case  trap Number  of 

getUI d=>  ...return  user's  Id.,  end  getUId 
k i 1 1  =  >  ...set  bits  tc  kill  a  process...  end  kill 
hiccup->  find  of  time  slice}" 
if  user  was  killed  then 

exit  {From  request  loop} 
end  if 
end  hiccup 

prccessFxit->  {Suicide} 
exit  {Iron  request  loop} 
end  Process Sx it 
f  c  rk  =  > 

Farily.Fcrk  {Vake  up  another  envelope} 
end  fork 

. . . ether  requests . . . 
end  case 


end  loop 

•  •  • 

Family .  P.eleaseUser  {Death,  of  user} 


that 
user 
ou  t 


Jr oh  the  enve 
is  invoked 
'  s  vie w point, 
requests  give 


lope's  v  i  e  v  p  o  i  n  t , 
ir.  order  tc  get 
the  envelope  is  a 
n  i:i  the  form  of 


the  user  is  a  subroutine 
a  r.  e  v;  request.  From  the 
subroutine  that  carries 
syster  calls  (traps).  In 


reality,  the  two  behave  a  coroutines  passing 
and  forth  as  they  switch  between  the  system 
and  the  user  domain  (iser  partition). 


control  back 
domain  (TUNIS ) 


Modularity  ir  TUNIS 

rUNIS's  modularity  offers  the  following  advantages. 


1 

X 


Maintenance  and  pert ability. 


CF  tightly 


limits  the  visi¬ 


bility  of  the  internals  of  modules.  Fence  a  module  can  be 
maintained  or  replaced  without  fear  cf  undesired  or  unknown 
accesses  tc  the  module's  private  data  or  algorithms.  For 
example ,  the  scheduling  algorithm  used  by  the  Memory  Manager 
can  be  extensively  modified  without  effecting  the 


, 

. 


, 
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correctness  of  other  nodules. 

2.  Testing.  Fe cause  of  the  relatively  narrow  interfaces  of 
each  major  nodule,  it  is  not  difficult  to  test  nodules  in  a 
simulated  node.  In  fact  most  cf  TUNIS'S  nodules  have  been 
executed  under  a  simulation  kernel.  This  simulation  kernel 
makes  a  user  process  behave  as  if  it  were  multiple  CE 
processes,  sc  most  of  TUNIS  can  be  executed  under  itself. 

3.  Proofs.  Eventually  we  would  like  to  try  to  prove  parts 
(or  all)  of  TUNIS  correct.  The  obvious  approach  is  to  for¬ 
mally  specify  each  of  the  major  nodules  and  to  prove  then 
individually  correct.  Proofs  of  these  modules  will  be  non¬ 
trivial  and  nay  require  r e-inplenenti ng  nodules  to  make  then 
amenable  to  proof  techniques. 


Summary 

This  paper  has  giver,  an  overview  cf  the  goals  and 
organization  of  the  TUNIS  operating  system.  It  is  intended 
to  be  a  high  performance  production  operating  system  that  is 
compatible  with  Version  7  of  UNIX.  It  is  intended  to  be 
nor  table  and  to  have  a  clean  internal  structure. 
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Concurrent  Euclid  ( Version  J_)  Distribution  Policy 


Fbis  policy  describes  Version  1  of  tne  Concurrent  Euclid  Compiler 
( called  tne  CE  Compiler  in  tne  following)  and  the  conditions  under  wnicn  it  is 
distributed  by  tne  Computer  Systems  Research  Group  (CSRG),  University  of 
Toronto . 

usage  f'ee:  An  institution,  company,  or  individual  becomes  an  authorised  user 
of  the  CE  Compiler  upon  payment  of  the  usage  fee.  This  fee  is  for  the  first 
system  at  an  installation.  Additional  fees  must  be  paid  for  subsequent  sys¬ 
tems;  bulK  discounts  are  possible.  Payment  of  this  fee  authorises  the  insti¬ 
tution  to  use  tne  CE  Compiler  on  a  single  computer.  A  reduced  "hardship"  fee 
can  be  requested  for  non-commercial  research  not  having  sufficient  funding. 

Duplication :  The  autnorised  user  may  make  a  reasonable  number  of  copies  of 

tne  CE  Compiler  for  internal  back-up  purposes  only.  The  authorised  user  is 
specifically  not  authorised  to  duplicate  for  others,  sell,  or  give  away  the  CE 
Compiler.  The  user  must  exercise  due  care  to  ensure  that  the  CE  Compiler  in 
nis  posession  is  not  duplicated  by  unauthorised  persons.  The  authorised  user 
may  duplicate  ana  sell  a  reasonable  number  of  copies  of  CE  Compiler  documenta¬ 
tion  within  nis  own  organization . 

uwnersnip :  The  CE  Compiler  ana  its  documentation  remain  the  property  of  CSRG. 

The  above  fees  are  for  tne  usage  of  the  CE  Compiler  as  indicated. 

Crecit :  The  user  must  give  full  credit  to  the  Computer  Systems  Research  Group 
and  tne  University  of  Toronto  in  all  material  referencing  the  Compiler,  and 
continue  the  name  "Concurrent  Euclid"  in  all.  uses  of  the  Compiler. 

Contact :  All  inquiries  regarding  the  CE  Compiler  should  be  addressed  to: 

Concurrent  Euclid  Distribution  hanager 
Computer  systems  Research  Group 
University  of  Toronto 
Toronto,  Ont.  M5S  1 AC  CANADA 

pnone:  (Alo)  97a-o9o5,  Tuesday  and  Thursday,  10—5  (Eastern  Time). 

Release :  University  of  Toronto  policy  requires  that  a  signed  copy  of  tne 
enclosed  software  release  form  accompany  each  request  for  authorization  as  a 
user  of-  the  CE  Compiler. 

Language  extensions  and  modification :  The  user  is  allowed  to  adapt  the  com¬ 
piler  for  nis  own  purposes  and  to  extend  tne  Concurrent  Euclid  language.  How¬ 
ever,  in  tne  interests  of  program  portability,  the  user  agrees  not  to  change 
the  compiler  sucn  that  it  no  longer  supports  tne  basic  language  as  described 
in  "Specification  of  Concurrent  Euclid"  by  J.  R.  Coray  and  R.  C.  holt. 
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■ftegug.st  for  Concurrent  Cue  lid  Compiler  ( Version  1) 

Please  send  a  distribution  tape  containing  the  CE  Compiler.  1  have  read 
ana  agree  to  the  conditions  set  out  in  the  Concurrent  Euclid  Compiler  (Version 
i)  Distrioution  Policy.  A  usage  fee  should  be  invoiced  as  shown  below.  The 
Cc  compiler  Release- iorm  on  the  reverse  of  this  page  has  been  signed..  A  pho¬ 
tocopy  or  my  UNIX  licence  is  attached  (source  or  binary). 

Signature _ _ _ _ __ _ _  Name _ 

Position _ Date 


lnsti tut ion _ 

checx  one: 

_  Usage  fee  of  $500*  to  be  invoiced  upon  shipment  of  the  compiler. 

_  usage  fee  of  $200  for  non-profit  educational  institution. 

_  Reducea  "hardsnip"  fee  of  $50  for  non-commercial  research  use 

only .  Attach  brief  letter  explaining  why  you  cannot  pay  the 
stanaard  fee  and  the  specific  use  to  be  made  of  the  compiler. 

specify  distribution  medium  desired: 

_  9-tracx  oOQ-bpi  magnetic  tape 

_  9-tracx  1oOO-bpi  magnetic  tape 

_  Utner  (contact  CSRG  first) _ 

CPU  autnorised  to  run  Concurrent  Euclid  Compier  (Version  1): 

CPU  Model _ _ _ _ 

CPU  berial  Number  (or  description) _ _ _ 

Name,  address,  and  phone  number  for  distribution: 


Pnone 

Name,  address,  and  phone  number  for  invoicing: 

Game  as  above,  or 

_ _ _ _ Phone _ 

*  Users  paying  tne  $500  fee  may  use  the  compiler  for  commercial 
purposes;  others  may  not. 
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CONCURRENT  EUCLID  COMPILER  (VERSION  1)  SOFTWARE  RELEASE  FORM 
(CONDITIONS  ON  WHICH  COMPUTER  SOFTWARE, 

data  bases  and  other  research  products 

are  FURNISHED  BY  THE  UNIVERSITY  OF  TORONTO) 

In  consideration  of  tne  receipt  from  the  University  of  Toronto  of  one 
copy  of  a  computer  program,  data  base,  or  other  research  product,  designated 
as  tne  Concurrent  Euclid  Compiler  ( Version  _1_) ,  and  nereinaf  ter  called  the 
work,  which  work;  was  created  by  Richard  <C.  Holt  and  James  _R.  Cordy , 
nereinaf ter  called  the  autnors ,  the  undersigned  hereby  agree: 


1 .  To  acknowledge  on  any  published  copies  or  in  any  other  use  of  the  work 
the  authorship  of  the  work  and  tne  fact  that  the  work  was  made  at  the 
University,  and  to  affix  or  apply  proper  copyright  notice  on  all  copies 
(i.e.,  Copyright  (c)  19&1  by  the  University  of  Toronto). 

1.  To  recognize  tnat  the  University  maxes  no  warranty  of  any  kind  and  does 
not  guarantee  maintenance  or  revision  of  tne  work. 

The  undersigned  hereby  release  and  forever  discharge  The  Governing  Coun¬ 
cil  of  tne  University  of  Toronto,  its  servants  and  agents  and  the  authors  and 
tneir  respective  heirs,  executors,  administrators,  successors  and  assigns 
(collectively  called  tne  "releasees"),  of  and  from  any  and  all  liability  for 
any  loss,  costs  or  damages  that  the  undersigned  may  at  any  time  suffer  or 
incur,  and  tne  undersigned  undertake  and-  agree  to  indemnify  the  releasees  and 
eacn  of  tnem  and  save  them  harmless  from  and  against  any  and  all  claims, 
demands ,  actions,  causes  of  action,  suits,  damages,  costs  and  expenses  that 
tney  or  any  of  tnem  may  at  any  time  suffer  or  sustain  at  the  instance  of  any 
person  to  wnom  or  corporation  to  which  the  undersigned  may  disclose  or  furnish 
tne  work  or  any  copy,  modification  or  part  thereof  or  any  application  or  use 
thereof,  for  or  by  reason  of  any  matter  or  tning  arising  or  resulting  from  or 
otnerwise  in  connection  witn  the  said  work  or  any  copying,  modification  or 
part  tnereof  and  any  application  or  use  thereof,  including  without  limitation, 
any  defects,  errors  or  limitations  in  the  said  work,  copy,  modification  or 
part,  it  being  expressly  understood  and  agreed  by  the  undersigned  that  while 
tne  releasees  have  made  reasonable  efforts  to  avoid  errors,  tney  disclaim  and 
are  absolved  from  any  and  all  liability  in  connection  therewith  as  aforesaid. 

IN  WITNESS  WHEREOF  1/we  have  hereunto  set  my/our  hand(s)  this  _  day 

of  _ ,  19 _ • 

IN  ThE  PRESENCE  OF: 


Witness 


(Signature  of  recipient) 


Witness 


(Signature  of  recipient) 


